Subject: Re: Open Item List for Release 1 DLSw Standard

From: Lakshman Garikapaty <[email-masked]>
Date: Tue, 7 Jun 94 16:38:37 EDT

Frank,

> Instead of adding an extra field for the header length, why not change
> the meaning of one of the 'message length' fields since it appears twice
> in the control header? If the SSP protocol is going to scale well in
> large networks we need to be aware of the SSP header overhead.

 There is already such field in the current dls message. It's usage 
(currently it is hardcoded to 72) and it's field position is not at the
right place to do what you want. This field is called Header length (it's
offset is 18 bytes)

 I think we need to reduce this header length to 8bits and move it's 
position to one of the reserved fields in the information message. The
reason to do this is to know whether we are dealing with information
message or control message instead of doing the way i suggested in 
my previous mail. (and also the reasons you cited too)

Think about it.

Lakshman.

---

From: Frank Bordonaro <[email-masked]>
Date: Tue, 7 Jun 94 14:21:52 PDT

Lakshman,

> my previous mail. (and also the reasons you cited too)

Yes. Moving the 'header length' to someplace such as the byte 1 reserved
field would achieve the desired result. 

In addition to this, it would be great to consider the usage of the 
following fields:

  1. Duplication of the message length field in control messages.
     Why? What is the gain?
  2. Origin and Target Transport Ids.
     The TCP connection is based on matching TCP ports, so why include 
     this information in every control message? How is it used?
  3. What is the significance of 12 bytes of reserved fields? This is
     a significant amount of excess baggage.

The above information consumes 22 bytes, assuming I counted correctly,
and its value is unclear to me. Any explanation would be appreciated.

Frank